The GSMA (Global System for Mobile communications Association) agreement IR.65 covering the IMS (IP Multimedia Subsystem) Roaming and interconnect guidelines introduced requirements for routing of media for voice & video over IMS when a call originator is roaming. In this case routing should be at least as optimal as that of a current Circuit Switched (CS) domain. Furthermore, a charging model for roaming used in the CS domain shall be maintained for voice & video over IMS.
To meet these GSMA requirements a solution necessitates that the user plane is not routed towards a HPLMN (Home Public Land Mobile Network) of the A-party, unless so desired by the HPLMN of the A-party. The requirement is met by the deployment of P-CSCF (Proxy-Call Session Control Function) functionality in a VPLMN (Visited Public Land Mobile Network) and use of a TRF (Transit and Roaming Function) which receives the call related signalling after it has been processed by the A-party HPLMN (so called VPLMN Routing). This allows the A-party VPLMN to send both control and user plane towards the destination and therefore replicate the current CS voice & video roaming model.
To fulfill the above requirements the GSMA requested 3GPP (3rd Generation Partnership Project) to work out the detailed architecture and stage 3 specifications. RAVEL (Roaming Architecture for Voice over IMS with Local Breakout) is the 3GPP specification project name for this work. It was completed as part of 3GPP release 11 in Q4 2012. The term RAVEL has not been included into the actual 3GPP specifications, but the term RAVEL is used within the context of the present application to refer to the specification parts introduced into the 3GPP specifications by the RAVEL specification project.
A number of specifications outline the detailed mechanism for RAVEL namely 3GPP release 11.7.0 versions of TS 23.228 and TS 24.229.
TS.23.228 specifies that the HPLMN shall decide whether to perform the loopback procedure based on local policy and on knowledge of the support of the procedure in the VPLMN. Loopback is further clarified and specified by that the HPLMN shall send an indication to the VPLMN that this session set-up is a loopback to allow differentiation from any other incoming call. By this means the VPLMN is able to apply the correct treatment for this looped incoming leg including charging, service invocation on behalf of the HPLMN, and routing decisions.
The 3GPP TS 23.228 specification further describes an architecture whereby the P-CSCF is located in the visited network with VPLMN loopback possibility. The overall architecture defined in this specification for IMS Local Breakout with P-CSCF located in visited network and with VPLMN loopback possibility is shown in FIG. 1 and thereby represents prior art.
To further illustrate the prior art procedure, FIG. 2 shows a procedure flow diagram illustrating a session establishment between a UE (user equipment) 210 roaming in a VPLMN 300 to a further UE 250 belonging to a further HPLMN 204, where the UE 250 is roaming in a further VPLMN 206. In other words, this covers a session between two roaming subscribers of different HPLMN.
The roaming UE 210 of the A-party sends a session invitation to the P-CSCF 214 via the P-GW (Proxy-GateWay) 212. The P-CSCF 214 forwards the session invitation to the IBCF (Interconnection Border Control Function) 216. Based on operator policy, the P-CSCF adds a reference to a preferred TRF (Transit and Roaming Function) 230.
This first IBCF 216 in the VPLMN 300 allocates a TrGW (Transit GateWay) 260 for the media and follows standard optimal media routing procedures when forwarding the session invitation to allow this TrGW 260 to be bypassed if the session invitation later returns to the VPLMN 300 and no other intermediate nodes anchor the media before the request returns.
A transit network (not depicted in FIG. 2) and a IBCF 218 in the HPLMN 304 forward the session invitation to the S-CSCF 220 of the A-party. Nodes in the transit network and the IBCF 218 in the HPLMN 304 support optimal media routing procedures and allow their TrGWs (not depicted in FIG. 2) to be bypassed. Then the S-CSCF 220 performs service invocation with the help of a TAS (Telephony Application Server) 222. The HSS (Home Subscriber Server) 224 stores the related subscriber data of the A-party.
The S-CSCF 220 performs a routing decision, and based on local policy and on the facts that the UE 210 is roaming, a roaming agreement for VPLNM 300 call routing is in place, and home routing is not required, the S-CSCF 220 decides to route back the session invitation to the VPLMN 300 for further session routing. A loopback indicator is included in the session invitation to inform the VPLMN 300 that this session invitation is being routed back to the VPLMN 300 for session routing. If a reference to the preferred TRF 230 is available in the request, the S-CSCF 220 uses this information to route the session back to the VPLMN 300. If a reference to the preferred TRF 230 is not available, the S-CSCF 220 uses a default derived address to the TRF 230 to route the session back to the VPLMN 300.
The IBCF 226 in the HPLMN 304 and the transit network (not depicted in FIG. 2) forward the session invitation towards the indicated TRF 230 in the VPLMN 300. Functions in the transit network support optimal media routing procedures and allow their TrGWs to be bypassed.
The IBCF 228 in the VPLMN 300 receives the session invitation, notes that the SDP (Session Description Protocol) includes an alternative media address within the VPLMN 300 that allows bypassing of allocated TrGWs, applies optimal media routing procedures to remove any TrGWs allocated between the VPLMN 300 and HPLMN 304, and forwards the request to the indicated TRF 230.
Based on the loopback indicator, the TRF 230 detects that this is a loopback request. The TRF 230 then routes the session invitation toward the destination network. In this scenario the B-party UE 250 is determined to be available in a IMS network, so the session invitation is routed towards the B-party through an IBCF 232 in the VPLMN 300 and a transit network (not depicted in FIG. 2) to a IBCF 234 of the HPLMN 204 of the B-party UE 250.
The IBCF 234 of the HPLMN 204 then forwards the session invitation to the S-CSCF 236 of the B-party in the HPLMN 204. Then the S-CSCF 236 performs service invocation with the help of a TAS 238. The HSS 240 stores the related subscriber data of the B-party.
The S-CSCF 236 performs routing decision, and since the UE 250 of the B-party is roaming in a further VPLMN 206 the session invitation is forwarded via IBCF 242, a transit network (not depicted in FIG. 2) to a IBCF 244 of the further VPLMN 206.
The session invitation is delivered to the UE 250 via the P-CSCF 246 and the P-GW 248 of the VPLMN 206.
The above description covers the handling and routing of the session invitation control signaling (solid arrows in FIG. 2). The handling and routing of the related session user plane is shown as dashed arrows in FIG. 2.
The related session user plane originates in the UE 210 of the A-party and is routed via the P-GW 212 and TrGW 260 of the VPLMN 300 where the A-party is roaming. From the TrGW 260 the user plane is directed straight to the TrGW 262 of the B-party's HPLMN 204. From there the user plane is routed to the TrGW 264 of the VPLMN 206 where the B-party is roaming. There the user plane is sent via the P-GW 248 to the UE 250 of the B-party.
As can be seen from FIG. 2 and the above description, the routing of the user plane follows the same principles as the current CS voice & video roaming model.
Whilst 3GPP covers mechanisms for the VPLMN 300 to recognize a loopback session, 3GPP does not explain how the HPLMN 304 (from VPLMNs 300 perspective the “served network”) shall be recognized and identified by the VPLMN 300.
In IMS roaming scenarios the need to identify the HPLMN 304 in loopback situations is necessary. A number of use cases being pushed by subscribers of the IMS network require that the VPLMN 300 is able to identify the HPLMN 304. The use cases may be any of the following: Roaming partner recognition & assertion; Service execution on behalf of served network (roaming partner); Correct charging and accounting information issued by VPLMN.
In CS based networks HPLMN determination is based on the IMSI (International Mobile Subscriber Identity) which provides both an identification of the HPLMN and the user. However IMSI is not available or not used in this IMS network scenario.
Furthermore, today it is not possible for the VPLMN to determine the HPLMN if a transit network is between them, which is typically the case in today's networks.
To meet the requirements for charging and accounting based on a home communication network and to invoke services on behalf of the home communication network, it is required for a visited communication network to determine a home communication network of a user equipment roaming in the visited communication network.